I'm not sure how to test this before merging as it's a workflow change and relies on a dependabot PR being created after the event?

There is obviously some risk it automation that modifies PRs, but this doesn't skip the requirement for two user reviews, so I think it's worth it, if it works, so reduce the dependabot manual effort we need now.

@stevenhorsman I was trying something similar, it's immensely frustrating: the culprit here seems to be that after a workflow-triggered change to the PR new test runs aren't triggered, because actions triggered by workflows are prohibited from triggering another automation (presumably to break loops).

I had a comment-based trigger in mind ("tidy-plz"), but I failed due make it work pleasantly due to the above restrictions.

@stevenhorsman I was trying something similar, it's immensely frustrating: the culprit here seems to be that after a workflow-triggered change to the PR new test runs aren't triggered, because actions triggered by workflows are prohibited from triggering another automation (presumably to break loops).

Yeah, I read that restriction, but was hoping that we could manually re-run the CI after the auto-fix is done on the PR, which isn't great, but it's better than having to manually fix the change?

I thought abou the same, but how will you do that? afaict you have to push an empty commit manually , b/c you cannot run test for the workflow commit. if you have to do that, then you can just run mod tidy locally, too. It‘s mad…

I thought abou the same, but how will you do that? afaict you have to push an empty commit manually , b/c you cannot run test for the workflow commit. if you have to do that, then you can just run mod tidy locally, too. It‘s mad…

Oh - I was hoping that re-running the tests would pick up the new change, but I guess their context is for the original sha, not the new one, so that wouldn't work 😞

I wonder whether it would be worth trying something like https://github.com/devops-infra/action-commit-push?tab=readme-ov-file#-advanced-example which looks like it lets you add a commit and then create a new PR from it? If that works we could probably extend it to close the original PR. It's not nice, but could be worth a try?

yes, I think creating a new PR, based off the dependabot PR's branch could be an option... can workflows create PRs that will run tests?

yes, I think creating a new PR, based off the dependabot PR's branch could be an option... can workflows create PRs that will run tests?

I can try and test it

Very interesting approach :-) I'm wondering if it would be possible to close the original PR after creating this one automatically from within the PR. That should take care of the dependabot updates as it should notice the previous PR was closed and create a new PR instead, shouldn't it? (unless our closing note states to ignore this change)

Ok, I've tried to update this to include the new proposal - do the go mod tidy, create a new PR (which hopeful will run the CI) and then close the original PR. Again - I'm not sure that it will work, or how to test it before merging, but maybe it's worth a try?

Ok, I've tried to update this to include the new proposal - do the go mod tidy, create a new PR (which hopeful will run the CI) and then close the original PR. Again - I'm not sure that it will work, or how to test it before merging, but maybe it's worth a try?

I think I tested it by pushing a (broken) dependabot PR's branch to my fork and then opening a PR (on my fork) myself

I think we'll have to test it. I replaced some PRs by manual ones before, important is not to include "ignore" or such (which extends the dependabot ignore list). But brief check with AI wasn't much optimistic and it suggested using:

on:
  pull_request_target:
    types: [opened, synchronize, reopened]

instead. Anyway I'd prefer the closing if it works as I'd expect:

upstream  - 0.1
dependabot detects 0.2 and creates PR
workflow creates 0.2 + go mod tidy and closes dependabot 0.2 PR without saying to ignore this further
dependabot detects 0.3 and creates PR
workflow creates 0.3 + go mod tidy and closes dependabot 0.3

(when we merge the 0.2 or not). If it doesn't work this way we'd have to find another solution.

Maybe I've misunderstood something, but I believe if you close a dependabot PR without a reason given then it defaults to only ignore that specific version and on the next bump it will create a new PR, so I don't need a specific message in the close?

That's how I understand it as well so I'm all in for this version. AI thinks otherwise so let's just give it a try and see how it turns out (we just need to know we should pay attention to it)

So it appears to not work on my fork: https://github.com/stevenhorsman/cloud-api-adaptor/actions/runs/21143017918/job/60801970374 but it's not helpful in that the pull_request action fails with no message that I can see 😿

2026-01-19T15:32:50.1105322Z Inputs:
2026-01-19T15:32:50.1105660Z   add_timestamp:       false
2026-01-19T15:32:50.1106232Z   amend:               false
2026-01-19T15:32:50.1106488Z   commit_prefix:       
2026-01-19T15:32:50.1106806Z   commit_message:      chore: Auto-run go mod tidy after Dependabot update
2026-01-19T15:32:50.1107160Z   force:               false
2026-01-19T15:32:50.1107371Z   force_with_lease:    false
2026-01-19T15:32:50.1107563Z   no_edit:             false
2026-01-19T15:32:50.1107778Z   organization_domain: github.com
2026-01-19T15:32:50.1108220Z   target_branch:       

Could it be the empty target branch (not really skilled with this gh action but to push one usually needs a branch). Trying force shouldn't harm as well ;-).

so I think the original issue I faced last week was that pull_request target is fundamentally read only, so add permissions doesn't make a difference. I switched to pull_request_target to resolve this, but am now seeing strange behaviour where the go tidy isn't having an impact this this workflow, so still trying to debug this...

Update: I worked out the issue - pull_request_target meant that by default it was checking out the target branch, not the PR source one, so the changes were missing 🥹

so I think the original issue I faced last week was that pull_request target is fundamentally read only, so add permissions doesn't make a difference. I switched to pull_request_target to resolve this, but am now seeing strange behaviour where the go tidy isn't having an impact this this workflow, so still trying to debug this...

Update: I worked out the issue - pull_request_target meant that by default it was checking out the target branch, not the PR source one, so the changes were missing 🥹

Yeah, the good old rebase-atop-of-the-latest-target-branch :-) Hopefully it's going to help.

Unfortunately I'm hitting the same issue as last week with the failure on the commit action, despite the pull_request_target switch, so either than wasn't the issue, or something else is going on. Unfortunately I think I'm out of ideas for now:
https://github.com/stevenhorsman/cloud-api-adaptor/actions/runs/21356498594/job/61471834714

Did you try forcing the target_branch? Or, just for testing, how about using pure bash?

Did you try forcing the target_branch? Or, just for testing, how about using pure bash?

Yeah, I tried force and force_with_lease options.